bugfix(physics): Prevent dead units from repeatedly dealing crash damage on collision with non-buildings by Stubbjax · Pull Request #2204 · TheSuperHackers/GeneralsGameCode

Stubbjax · 2026-01-28T03:15:46Z

Closes #2015

This change fixes an issue where dead vehicles repeatedly trigger VehicleCrashesIntoNonBuildingWeapon when colliding with mines, causing continuous damage to nearby units and structures.

This weapon is hardcoded into the physics update, and is fired when a vehicle falls onto a non-building object - the intent being that a vehicle deals some 'crush' damage to a victim it lands on. It is especially problematic in the case of mines as the mines cannot destroy the already-dead vehicle. The issue is most apparent with Technicals due to their frequent involvement in bombing runs and their tendency to fling themselves forwards upon death.

The fix makes the weapon only deal damage to the collided target.

There is also a building-specific crash block that fires VehicleCrashesIntoBuildingWeapon when a vehicle crashes into a building, however this results in the immediate destruction of the crashing vehicle, and so is not as problematic.

Before

The Propaganda Center dies due to dead Technicals firing VehicleCrashesIntoNonBuildingWeapon every frame

YES_DAMAGE.mp4

After

The Propaganda Center survives unscathed as VehicleCrashesIntoNonBuildingWeapon only targets the mines

NO_DAMAGE.mp4

greptile-apps · 2026-01-28T03:23:43Z

Greptile Summary

This PR fixes a bug where dead vehicles (notably Technicals after bombing runs) would fire VehicleCrashesIntoNonBuildingWeapon every physics frame on collision with objects like mines, causing continuous AoE damage to nearby units and structures. The fix replaces the original createAndFireTempWeapon (which fires an AoE blast centered on the crashing vehicle) with a direct attemptDamage call targeting only the colliding object (other).

The new path is guarded by #if RETAIL_COMPATIBLE_CRC, so the original AoE behavior is preserved when building in CRC-compatible mode for replay parity with retail.
DamageInfo is correctly populated (type, death type, source ID, source player mask, and primary damage with a neutral WeaponBonus), matching the fields set by the standard dealDamageInternal path for a direct-hit victim.
The fire FX is preserved via an explicit FXList::doFXObj call. The concern about missing m_sourcePlayerMask raised in previous review threads is addressed in this PR.

Confidence Score: 5/5

Safe to merge. The change is narrowly scoped to the non-building crash damage path, the original retail behavior is fully preserved under the CRC guard, and the direct damage call populates all required DamageInfo fields correctly.

The fix correctly replaces an AoE weapon blast at the crashing vehicle position with a single targeted attemptDamage call on the colliding object. All fields written by the standard dealDamageInternal path for a direct-hit victim are present, including m_sourcePlayerMask which was the concern from prior review threads. The WeaponBonus default gives base damage with no bonuses, which is appropriate for a physics-driven crash event.

No files require special attention.

Important Files Changed

Filename	Overview
Generals/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp	Replaces AoE crash weapon fire with a targeted direct damage call on the colliding object, with `m_sourcePlayerMask` properly populated; gated behind `#if RETAIL_COMPATIBLE_CRC` to preserve original behavior for CRC builds.
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp	Identical fix applied to the Zero Hour version of PhysicsUpdate.cpp; no differences in logic relative to the Generals copy.

_{Reviews (6): Last reviewed commit: "tweak: Assign source player mask" | Re-trigger Greptile}

Mauller · 2026-01-28T08:08:12Z

This doesn't properly resolve #2015, the issue with aircraft landing on mines is that the aircraftSlowDeathBehaviour module for the chinook is waiting to see when the unit hits the ground. But it never does and remains floating over the mines above the ground detection threshold.

The issue is that the mines block the slow death code from detecting when the chinook hits the ground properly and prevents the carcus from ever clearing itself.

Stubbjax · 2026-01-28T08:26:11Z

This doesn't properly resolve #2015, the issue with aircraft landing on mines is that the aircraftSlowDeathBehaviour module for the chinook is waiting to see when the unit hits the ground. But it never does and remains floating over the mines above the ground detection threshold.

The issue is that the mines block the slow death code from detecting when the chinook hits the ground properly and prevents the carcus from ever clearing itself.

That sounds like a separate issue? This fix targets the issue as described; "GLA Technical kills/damages building when dying by China Mines".

Mauller · 2026-01-28T08:43:35Z

This doesn't properly resolve #2015, the issue with aircraft landing on mines is that the aircraftSlowDeathBehaviour module for the chinook is waiting to see when the unit hits the ground. But it never does and remains floating over the mines above the ground detection threshold.
The issue is that the mines block the slow death code from detecting when the chinook hits the ground properly and prevents the carcus from ever clearing itself.

That sounds like a separate issue? This fix targets the issue as described; "GLA Technical kills/damages building when dying by China Mines".

Ah yeah, i glanced over it and read the bit about migs and chinooks in the issue as well.

The other week Fish and i were looking into the same issue but with aircraft and it is a problem with the death behaviour modules.

I don't think your change here will fix their behaviour since they are never properly set to being effectively dead since they remain stuck in their death crash handling.

Stubbjax · 2026-01-28T08:47:30Z

I don't think your change here will fix their behaviour since they are never properly set to being effectively dead since they remain stuck in their death crash handling.

Is effectively dead not exactly the status that should apply here? As far as I'm aware that status is applied as soon as health becomes depleted.

Mauller · 2026-02-03T08:41:05Z

I don't think your change here will fix their behaviour since they are never properly set to being effectively dead since they remain stuck in their death crash handling.

Is effectively dead not exactly the status that should apply here? As far as I'm aware that status is applied as soon as health becomes depleted.

I would need to check again, have you seen if this also prevents falling planes and helicopters applying continuous damage when they land on mines?

Or checked if falling planes and helicopters apply any damage when landing on things?

Stubbjax · 2026-02-03T09:14:43Z

I would need to check again, have you seen if this also prevents falling planes and helicopters applying continuous damage when they land on mines?

This will affect anything that would have previously repeatedly applied VehicleCrashesIntoNonBuildingWeapon on collision with mines. This should include aircraft as they all have the necessary VEHICLE KindOf, but I have not explicitly tested it.

xezon · 2026-02-26T18:20:06Z

 					if (obj->isKindOf(KINDOF_VEHICLE))
+#else
+					// TheSuperHackers @bugfix Stubbjax 28/01/2026 Prevent dead units from repeatedly dealing damage.
+					if (obj->isKindOf(KINDOF_VEHICLE) && !obj->isEffectivelyDead())


I suspect this fix is not correct. I put a breakpoint into this branch and on the very first hit the Object is already dead, which means that this weapon now never fires once.

Can you clarify what you mean? You have described the fix as intended, which is to prevent crash damage from triggering if the object is effectively dead.

Ok how do we know the intent is to not apply damage once when dead technical crashes?

We do not. We can only say the new intent is to not have it deal any damage in order to improve gameplay.

I expect that a dead vehicle crashing into something can apply damage once. For example if a plane is shot and its rubble hits the ground, then it applies collision damage once. Otherwise only alive vehicles would cause crash damage, which may not be intuitive for players. This is also more in line with what the original code did (incorrectly).

I suggest add 1 new bit flag to PhysicsBehavior, default it to 1, check if it is 1 before one of the createAndFireTempWeapon, and then set it to 0 afterwards.

This way, this physics weapon can only ever fire once.

When should it be reset to 1?

Check if there is a way to determine if a collision event is "new". I suspect PhysicsBehavior::onCollide keeps being called every frame because the object is not pushed away from the collider, but keeps intersecting while flying through it.

I'm still struggling to understand why such behaviour is desirable. Currently, if a dead unit falls on a non-building obstacle (e.g. rocks, mines, shipping containers, etc.), then it deals crush damage in a radius while in contact. Even if we reduce this to a single damage instance per obstacle, the behaviour is still effectively arbitrary and can yield confusing and unexpected results.

THE_ROCKS.mp4

So instead perhaps disable the crash damages entirely?

Piddox · 2026-04-06T10:14:49Z

This seems to have hit a stall. I would like to showcase how badly this bug impacts competitive gameplay in GO currently, by showing some clips I've saved over the last weeks:

Marakar vs TumStep in ZH League, prize pool $280:

MiKwArY vs BoYcaH^, same tournament ZH League:

Kill toll vs Raging_K, sponsored challenge by Yamen (they ended up replaying this game due to the bug):

Same set, next game:

And some ffg examples:
Massacre vs Logica:

2026-04-17.14-20-22.mp4

Rudwan vs Logica (instant ragequit):

2026-04-06.11-30-40.mp4

Memphis vs Rusty:

2026-04-06.11-29-39.mp4

Mamo in 3v3 50k TW:

2026-04-04.21-59-26.mp4

I could go on, this is just a fraction of the times I've seen it happening. Honestly, it's a plague infesting GO competitive gameplay, and since players don't know any better, it's bad for the reputation of both GO and TSH.

It appears we have a fix ready to be deployed here. It's just not completely clear whether the collision damage should not be applied at all (which this fix does), or whether the intended behavior of the EA devs was to have collision damage to occur once.

Would it be possible to continue that debate in a new issue, whilst merging this one to main, as a temporary fix, so that the players at least can enjoy this bug fix and not be confronted by this heavily game-impacting bug behavior?

xezon · 2026-04-18T19:03:28Z

Needs a decision. Current fix does not appear to be satisfying.

Stubbjax · 2026-04-19T02:16:06Z

Needs a decision. Current fix does not appear to be satisfying.

I think the ideal solution would be to forgo the isEffectivelyDead check and instead apply damage directly to the collided object(s) rather than spawning a weapon template.

So instead of:

TheWeaponStore->createAndFireTempWeapon(getPhysicsBehaviorModuleData()->m_vehicleCrashesIntoNonBuildingWeaponTemplate, obj, obj->getPosition());

We would have:

const WeaponTemplate* weaponTemplate = getPhysicsBehaviorModuleData()->m_vehicleCrashesIntoNonBuildingWeaponTemplate;

DamageInfo damageInfo;
damageInfo.in.m_damageType = weaponTemplate->getDamageType();
damageInfo.in.m_deathType = weaponTemplate->getDeathType();
damageInfo.in.m_sourceID = obj->getID();
damageInfo.in.m_amount = weaponTemplate->m_primaryDamage;

other->attemptDamage(&damageInfo);

This would mean only rocks or mines or whatever other prop objects would receive the damage directly, while nearby units and buildings remain unaffected. We could think about doing this for the building crash too, to avoid the inconsistent damage application entirely. We can then look at implementing dedicated death weapons for crashed aircraft further down the track.

Thoughts?

xezon · 2026-04-19T08:09:28Z

Can crashed units collide with multiple units or just ever one?

Stubbjax · 2026-04-19T08:10:57Z

Can crashed units collide with multiple units or just ever one?

Well it wouldn't be units, but yes, I imagine any applicable obstacles within the geometry bounds would run through onCollide.

xezon · 2026-04-19T08:23:21Z

It appears logical to only apply damage to directly collided things. It just needs to make sure to not re-apply the damage on every repeated collision event.

Stubbjax · 2026-04-19T08:24:58Z

It appears logical to only apply damage to directly collided things. It just needs to make sure to not re-apply the damage on every repeated collision event.

Does it matter if it does? We don't know what object(s) might be in the way. If we only apply e.g. 30 damage once to a 100-HP object, then the object will remain and potentially block the dead object.

xezon · 2026-04-19T09:25:34Z

But isn't the repeated damage exactly the problem here? A dead vehicle falling onto a building will not be pushed off the building. It will continueosly collide and spam damage events every logic frame.

Stubbjax · 2026-04-19T09:30:15Z

But isn't the repeated damage exactly the problem here? A dead vehicle falling onto a building will not be pushed off the building. It will continueosly collide and spam damage events every logic frame.

If the object collides with a building, the object is destroyed. The problem occurs when the object collides with non-building obstacles and spawns damage instances during those collisions which affect other nearby objects.

xezon · 2026-04-19T09:52:46Z

Ok. You can make a POC for this and then we see how that looks.

Stubbjax · 2026-04-19T11:55:21Z

Ok. You can make a POC for this and then we see how that looks.

Pushed an update. This essentially yields the same benefits as the original fix, with the added bonus that falling dead objects don't get stuck above destructible non-building obstacles.

Before

Colliding with an obstacle deals damage to nearby objects

LIX_CRASH_BEFORE.mp4

After

Colliding with an obstacle only deals damage to collided objects

LIX_CRASH_AFTER.mp4

xezon

Can you also prepare a change for the crash damage on buildings?

Stubbjax · 2026-04-28T16:44:40Z

Can you also prepare a change for the crash damage on buildings?

As part of this change or separately?

xezon · 2026-04-30T19:59:18Z

As part of this change or separately?

Can be separate if it requires seperate description.

Piddox · 2026-05-09T13:58:12Z

I see green ticks everywhere. Is there anything else needed for this to be merged into main?

xezon · 2026-05-09T14:23:36Z

I was waiting for the partner fix to merge them together

…llision with non-buildings

greptile-apps · 2026-05-20T05:55:56Z

Want your agent to iterate on Greptile's feedback? Try greploops.

Stubbjax self-assigned this Jan 28, 2026

Stubbjax added Bug Something is not working right, typically is user facing Minor Severity: Minor < Major < Critical < Blocker Gen Relates to Generals ZH Relates to Zero Hour NoRetail This fix or change is not applicable with Retail game compatibility labels Jan 28, 2026

xezon reviewed Feb 26, 2026

View reviewed changes

xezon reviewed Mar 1, 2026

View reviewed changes

Comment thread Generals/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp

xezon added Major Severity: Minor < Major < Critical < Blocker and removed Minor Severity: Minor < Major < Critical < Blocker labels Apr 20, 2026

xezon approved these changes Apr 20, 2026

View reviewed changes

xezon reviewed Apr 20, 2026

View reviewed changes

Comment thread Generals/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp Outdated

Stubbjax mentioned this pull request May 17, 2026

bugfix(physics): Prevent building crash damage from dealing damage to other objects #2723

Merged

Stubbjax force-pushed the fix-dead-unit-crash-damage branch from 426f7ef to bbd73fd Compare May 17, 2026 11:38

greptile-apps Bot reviewed May 17, 2026

View reviewed changes

Comment thread Generals/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp

Comment thread GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/PhysicsUpdate.cpp

Stubbjax force-pushed the fix-dead-unit-crash-damage branch from 4e17363 to fd6d974 Compare May 17, 2026 12:17

xezon approved these changes May 18, 2026

View reviewed changes

Stubbjax added 5 commits May 20, 2026 15:50

bugfix: Prevent dead units from repeatedly dealing crash damage on co…

e273f0c

…llision with non-buildings

bugfix: Only apply non-building crash damage to collided objects

13a8355

tweak: Add null checks

e7b27c9

tweak: Attempt to fire effects

c6bf9f2

tweak: Assign source player mask

f970d13

Stubbjax force-pushed the fix-dead-unit-crash-damage branch from fd6d974 to f970d13 Compare May 20, 2026 05:50

xezon changed the title ~~bugfix: Prevent dead units from repeatedly dealing crash damage on collision with non-buildings~~ bugfix(physics): Prevent dead units from repeatedly dealing crash damage on collision with non-buildings May 20, 2026

xezon merged commit 1594474 into TheSuperHackers:main May 20, 2026
17 checks passed

Conversation

Stubbjax commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Before

After

Uh oh!

greptile-apps Bot commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Uh oh!

Mauller commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Stubbjax commented Jan 28, 2026

Uh oh!

Mauller commented Jan 28, 2026

Uh oh!

Stubbjax commented Jan 28, 2026

Uh oh!

Mauller commented Feb 3, 2026

Uh oh!

Stubbjax commented Feb 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Piddox commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xezon commented Apr 18, 2026

Uh oh!

Stubbjax commented Apr 19, 2026

Uh oh!

xezon commented Apr 19, 2026

Uh oh!

Stubbjax commented Apr 19, 2026

Uh oh!

xezon commented Apr 19, 2026

Uh oh!

Stubbjax commented Apr 19, 2026

Uh oh!

xezon commented Apr 19, 2026

Uh oh!

Stubbjax commented Apr 19, 2026

Uh oh!

xezon commented Apr 19, 2026

Uh oh!

Stubbjax commented Apr 19, 2026

Before

After

Uh oh!

xezon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Stubbjax commented Apr 28, 2026

Uh oh!

xezon commented Apr 30, 2026

Uh oh!

Piddox commented May 9, 2026

Stubbjax commented Jan 28, 2026 •

edited

Loading

greptile-apps Bot commented Jan 28, 2026 •

edited

Loading

Mauller commented Jan 28, 2026 •

edited

Loading

Piddox commented Apr 6, 2026 •

edited

Loading